Support client cert validation (spki, hash, san)#5868
Support client cert validation (spki, hash, san)#5868rudrakhp merged 8 commits intoenvoyproxy:mainfrom
Conversation
f9b7336 to
0407b7e
Compare
|
hey hoping to get to this one in 1.5 weeks post v1.4 release |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5868 +/- ##
==========================================
+ Coverage 70.84% 70.93% +0.09%
==========================================
Files 220 220
Lines 37188 37259 +71
==========================================
+ Hits 26345 26429 +84
+ Misses 9295 9286 -9
+ Partials 1548 1544 -4 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
0407b7e to
2ebdd7e
Compare
|
Thanks @arkodg , sounds good! I fixed crds and will add some tests to make Codecov happy) |
2ebdd7e to
c8a342b
Compare
c8a342b to
e03472a
Compare
|
|
e03472a to
1d129c8
Compare
api/v1alpha1/tls_types.go
Outdated
There was a problem hiding this comment.
Should we name it PublicKeyHashes?
PublicKeyPins may be better here though. I'm just speaking from the perspective of a non-native English reader.
There was a problem hiding this comment.
I've chosen the name PublicKeyPins because the format base64(sha256(public key from cert in DER)) comes from Public Key Pinning Extension for HTTP rfc7469 where they have Public-Key-Pins HTTP header. But let me know if you still want me to rename it to PublicKeyHashes, I won't argue)
There was a problem hiding this comment.
I'd go with PublicKeyHashes or SPKIHashes because:
- It's easier to understand at a glance, without requiring background knowledge of Public Key Pinning Extension for HTTP rfc7469.
- Even though we use the same format of
Public-Key-PinsHTTP header here, the purpose is different.
cc @envoyproxy/gateway-maintainers please vote for
- PublicKeyHashes
- SPKIHashes
- PublicKeyPins
My vote is either 1 or 2
There was a problem hiding this comment.
I do like SPKIHashes, I've renamed the field. Ready to do it again if the vote suggest a different option)
zhaohuabing
left a comment
There was a problem hiding this comment.
Nit: Prefer to add yaml tests to the gateway API translator and xDS translator instead of individual go tests files.
|
@zhaohuabing I've added testdata as you requested to:
Do I have to delete all or some of go tests from the files below?
|
ef542b9 to
9d79c92
Compare
I think we wouldn't need clienttrafficpolicy_test.go and listener_test.go, but it's fine to keep them. |
eaa17f3 to
0d87295
Compare
Agree, these were duplicates of testdata, I've removed them. |
api/v1alpha1/tls_types.go
Outdated
There was a problem hiding this comment.
Nit: consider renaming it to OtherSANNameMatch orOtherSANMatch ?
All API types are in the same namespace, a more specific name would be better.
There was a problem hiding this comment.
SAN type OtherName is defined in section 4.2.1.6 Subject Alternative Name of rfc5280. Envoy and cert-manager follow this definition. That is why I'd prefer to not rename the field.
There was a problem hiding this comment.
OK, OtherNameMatch works for me.
There was a problem hiding this comment.
Oh, I'm sorry, only now I understand that you asked to rename the type and not the field! I agree I should definitely add "SAN" to the type name, I'll do it shortly.
There was a problem hiding this comment.
Renamed to OtherSANMatch
|
LGTM. @kinolaev Can you resolve the conflicts and fix the lint? |
Signed-off-by: Sergei Nikolaev <kinolaev@gmail.com>
Signed-off-by: Sergei Nikolaev <kinolaev@gmail.com>
Signed-off-by: Sergei Nikolaev <kinolaev@gmail.com>
Signed-off-by: Sergei Nikolaev <kinolaev@gmail.com>
Signed-off-by: Sergei Nikolaev <kinolaev@gmail.com>
Signed-off-by: Sergei Nikolaev <kinolaev@gmail.com>
Signed-off-by: Sergei Nikolaev <kinolaev@gmail.com>
0d87295 to
a01c7e6
Compare
|
Thank you @zhaohuabing, the conflicts are resolved and CI is green now) |
Signed-off-by: Rudrakh Panigrahi <rudrakh97@gmail.com>
What type of PR is this?
api: add
publicKeyPins,certificateHashesandsubjectAltNamesfields to ClientTrafficPolicy.spec.tls.clientValidationfeat(translator): translate these fields to tls validation context
What this PR does / why we need it:
This PR allows to validate a client certificate against a list of SKPI hashes, certificate hashes or SANs using
ClientTrafficPolicyWhich issue(s) this PR fixes:
#5909
Release Notes: Yes